Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0799/525

Internet Message Format | 1994-08-27 | 9KB

Date: Thu, 23 Jun 1994 15:58:34 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: Blocks
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9406231534.A12383-0100000@grad>
Mime-Version: 1.0
Precedence: bulk

Annius:

)pm> I prefer the "cursor equals block" concept. The (inserting) cursor
is a
)pm> zero length block, anything typed replaces the block's contents. In this
)pm> concept, an overwrite mode cursor would mark the one char under it
as a
)pm> block, anything typed or inserted replaces the block. Similarly, any
)pm> marked block will be replaced by typed or inserted stuff.
)
)I have one simple description for methods of the like:  this is too much
)thinking from  the perspective  of the  programmer.  Programmers  should
)care about  what  the USER  thinks.   Even while  a  user can  learn  to
)*understand* the windows/mac idea,  s/he will still keep making mistakes
)when using this system.

Obviously, you've not tried to implement this system before... either
that or you made it more complicated than it really is.  In reality, the
metaphor is nothing more than just a 'way' of looking at it.  It turns
out to take less to implement, because you don't have all the EXTRA CODE
required implement an INDEPENDANT block-handling system.  In the
big-cursor system, the block-handling and normal insertion code are the
SAME code, performing the same tasks, although you could do it
differently, but that would probably make it more difficult than the
other method.  And on top of that, it requires the user to LEARN a LOT
LESS.  And besides that, the user is no less likely to make mistakes
using your system than the big-cursor system.

Too much thinking for the programmer?  People developing and explaining
theories tend to over-explain things for the sake of giving multiple ways
of understanding the same thing.  And we implement this system because we
DO care about what the user wants and IS WELL ACCUSTOMED TO!

Too much thinking for the programmer?  Are you one of the proponents of
that short-cut config file?  Sheesh.


)I don't  understand the  fuss about  Control G  and Goto.   In both  the
)German and English standards,  Control L is used for Goto Line.

I don't actually care which is used, but if Ctrl-L is used for Goto Line
(which is fine for me), then something else will have to be
Redraw-Window.  How about Ctrl-A?  It's harmess enough.

But what about situations where it's not Goto Line that we want, but
rather Goto Icon, or Goto Byte, or something else?  I suppose if people
got used to ^L as 'goto', the wouldn't care.

Now, I could conceive (vaguely) of an application where the user would be
required to explicitly command the application to redraw the window
(refresh, update, etc.), due to the DESIGN of the application..... like
monitoring of real-time input where you don't care about a constant
update, just an update when you WANT it.  In this case, you'd need such a
shortcut.  How about Ctrl-A?


)If you have a desktop publishing or drawing package,  and you copy a few
)frames,   you'd  want  to  *ADD*  them  to  the  clipboard.   The   term
)'Append' only  makes   sense   in  applications   that   handle   LINEAR
)(one-dimensional) data.  So a general proposal should use the word  add,
)not append.

Very nice.  'Add' is unambiguous but not too specific.


)> >> Ctrl-A = Deselect marked (all), i.e. "Abandon" selection
)
)WOW! That makes three (four?) actions which all have the name "Abandon"!
)
You're right.  It's too much.  I prefer the terms "Hide Block", or
"Deselect Block".  Using the word 'all' in there doesn't seem to make
much sense.

)ct> I do that many times in Atariworks, as
)ct> well as selecting areas and simply hitting backspace to delete them.
)
)Hm.  If the Mac system were really  as orthogonal as people on the  list
)claim, hitting  backspace should  remove the  block PLUS  the  character
)right before the block;  for that's what is does when the block is  size
)0 (the cursor).  Similar for Delete.

Now, don't get silly on us.  If you have a real arguement against it,
fine, but don't give us useless comments.


)You mean 'real soon'? I'm impressed.  At the current pace,  that will be
)in couple of years.  I think that  by that time my home machine will  be
)an SGI.

A fellow SGI lover, eh?  :)  Did you know that SGI financially supports
its users groups, develops, supports, and advertizes new technology, has
a good customer service department, uses an optimized implementation of
UNIX, a very efficient GUI, and countless of other things that Atari
would never be caught dead doing?  Emphasis on the word 'dead' for
Atari.  Sheesh.


)og> CTRL Tab               Cycle Windows
)og> Shift CTRL Tab         Reverse Cycle Windows
)og> CTRL ESC               Close Top Window
)og> Shift CTRL Tab         Close All Windows
)
)I take it the last line should read 'Shift CTRL ESC'.  I think this is a
)great idea.   Let's  then  leave  W  and  U  completely  undefined,   so
)applications can freely choose what they want to do with those.

Yes.  They're all easy to hit with one hand, but none of them are
dangerous.  (I've accidentally hit Ctrl-Tab before, but that doesn't
really cause any harm.)  Plus, you can use W and U for more useful
things.  These are used only slightly more than Select-All, so it
wouldn't hurt too much to change them like this.


)   Shift Backspace:        Same as Backspace

And add     Shift Delete:   Same as Delete


And per your comment about dangerous applications... some dangers are
very difficult to 'implement out'.  It's best, most often, to change
something else, easier to change.



=========================
Warwick about abandoning abandon:

WHAT ABOUT:

   close window =
      if (changed)
      {  switch (ask_user)
         {  case Cancel
         :     do noting
         ;  case Abandon
         :     close
         ;  case Reload
         :     reload
         ;  case Save
         :     save,  close
         ;  case Save As...
         :     save as, close
   ;  }  }
      else
===========================
Talk about ugly code.  I'm sorry, but this is a mess.  You're violating
numerous rules of readable code.  Is that why you said not to cover this
subject?  And those semicolons and colons all lined up there are ugly,
distracting, and out of place.

How about go for something a little more normal?

    if (changed) {
        switch (ask_user) {
            case Cancel:
                do noting;

            case Abandon:
                close;

            case Reload:
                reload;

            case Save:
                save,  close;

            case Save As...:
                save as, close;
        }
    } else {
        ........
    }

There.  That's better.  Now that I can read it, I can ask you why you are
closing upon save.  Why?  That's the most annoying feature of First
Word.  Don't close on save.  If I want to close, I'll TELL it to close.



Ofir and [e-mail] said:
>
>I'm getting sick of people voicing preferences that are irresolvable
>on the arguments they give. Let's get back to looking at the
>conventions that exist and comming up with a standard that will enable
>the greatest ammount of TRANSFER from applications users are already
>familiar with. This confers a much greate advantage than any sort of
>half-baked mono-lingual mapping between a letter and its function (I
>can dig out a reference for this if anyone's interested). The
>guidelines must be an *evoloution*, its too late for starting from
>scratch.

I've been saying the same thing.  If we're to have this great amount of
transfer, then we have to be sure that one particular application type
isn't disadvantaged in some way, like having key-combinations that turn
out to be dangerous.  Making something easy to hit is very important, but
even more important is avoiding danger.

We need to make a standard that is robust, applicable to a wide range of
applications, and bullet-proof.  We can do it, but it'll take a lot of
work.  We've accomplished just about everything alre